Chapitre VI : La sécurité de l’application Hairbnb

"La sécurité n’est pas un produit, c’est un processus."

— Bruce Schneier
Expert en Cybersécurité

1. Introduction

1.1. Contexte et objectifs de l’analyse

Ce rapport présente une analyse de sécurité de l’application Hairbnb, développée dans le cadre d’un travail de fin d’études.

L’objectif principal est d’évaluer les mesures de protection des données personnelles et d’identifier les vulnérabilités potentielles du système.

Cette analyse s’appuie sur les connaissances acquises durant le processus de développement et les enseignements tirés des défis rencontrés lors de l’implémentation des fonctionnalités de sécurité.

Apprentissage par l’expérience : Cette analyse reflète un parcours d’apprentissage.

Chaque erreur commise pendant le développement de Hairbnb a été une opportunité d’améliorer mes connaissances en sécurité informatique.

1.2. Qu’est-ce que Hairbnb exactement ?

Pour ceux qui découvrent, Hairbnb c’est un peu l’Uber des coiffeurs"

L’idée est géniale :

Les client(e)s peuvent trouver une coiffeuse près de chez eux.

Les coiffeuses peuvent proposer leurs services et gérer leur planning.

Tout le monde peut laisser des avis et noter les prestations.

Mais derrière cette simplicité, il y a une complexité technique énorme !

On parle de :

Frontend = L’interface que vous voyez (boutons, formulaires, etc.).
Backend = Le serveur qui traite vos demandes en arrière-plan.
API = Le "postier" qui fait communiquer frontend et backend.
Base de données = L’endroit où on stocke toutes les infos.

1.3. Les enjeux de sécurité (et pourquoi ça me tient à cœur)

On ne rigole pas avec la sécurité dans ce type d’app.

Pourquoi ? Parce qu’on manipule des données ultra-sensibles :

1.3.1. Données personnelles

Noms, adresses, téléphones .
Photos de profil (oui, même ça peut être sensible !).
Historique de réservations.

Mon expérience : J’ai déjà vu des apps où les mots de passe étaient stockés en clair.
CATASTROPHIQUE ! Un pirate amateur peut récupérer la base et boom, il a accès à tout.

1.3.2. Géolocalisation

Adresses des coiffeurs.
Trajets des clients.
Zones de clientèle (le périmètre d’où viennent les clients).

Conformité RGPD : En Europe, le non-respect de la protection des données peut entraîner des sanctions administratives pouvant atteindre 4% du chiffre d’affaires annuel mondial ou 20 millions d’euros.^[1]

Prise de conscience : La découverte de ces montants d’amendes pendant mes recherches a été un déclic.

Cela a motivé une approche plus rigoureuse de la sécurité dès les premières phases de développement comme si l’application sera commercialisée dans le futur.

1.4. Méthodologie d’analyse

L’évaluation de la sécurité suit une approche structurée en quatre phases :

1.4.1. Phase d’exploration

Analyse de l’architecture du code.
Mapping des flux de données.
Identification des composants de sécurité.

1.4.2. Phase d’identification

Inventaire des mesures de protection existantes.
Détection des vulnérabilités potentielles.
Cartographie des points d’exposition.

1.4.3. Phase d’évaluation

Analyse de la conformité aux bonnes pratiques.
Test de résistance des mécanismes de sécurité.
Évaluation des risques identifiés.

Approche pragmatique : Cette méthodologie s’inspire des techniques de "Red Team" (équipe d’attaque) consistant à adopter le point de vue d’un attaquant potentiel pour identifier les failles du système.

1.5. Structure du document

Ce rapport s’organise autour des sections suivantes :

Architecture générale de sécurité : Vue d’ensemble des mécanismes de protection implémentés dans l’application.
Sécurité du frontend : Analyse des mesures de protection côté interface utilisateur, incluant l’authentification et la validation des données.
Infrastructure et reverse proxy : Configuration sécurisée de Nginx, gestion du domaine hairbnb.site et liaison avec l’application hébergée localement.
Sécurité du backend : Évaluation des protections serveur, notamment les contrôles d’accès et la protection des données.

Objectif pédagogique : Ce rapport vise à documenter les apprentissages réalisés pendant le développement et à servir de référence pour de futurs projets similaires.

1.6. Portée et limitations

Cette analyse couvre les composants principaux de l’application Hairbnb mais présente certaines limitations :

Les tests de pénétration approfondis dépassent le cadre de cette étude.
Dans le contexte d’un projet de fin de formation, les ressources financières limitées n’ont pas permis l’utilisation de certains services payants spécialisés (Veracode, SonarQube Premium, Auth0 Enterprise, services d’audit sécuritaire professionnels).
Les multiples restructurations du code durant le développement peuvent avoir introduit des vulnérabilités dans certaines parties de l’application.

Le statut d’étudiant et l’absence d’exposition directe au marché professionnel peuvent avoir occulté certains aspects sécuritaires spécifiques aux environnements de production

À l’issue de cette lecture, le lecteur devrait pouvoir :

✅ Comprendre les mécanismes de protection des données mis en place ✅ Identifier les forces et faiblesses du système de sécurité ✅ Évaluer les priorités d’amélioration ✅ Appréhender les enjeux de conformité réglementaire

"La sécurité informatique est un apprentissage permanent.
Chaque erreur commise pendant le développement de Hairbnb a été une leçon précieuse pour comprendre l’importance de sécuriser dès la conception."

— Retour d'expérience personnel

2. Architecture générale de sécurité

2.1. Vue d’ensemble du système

L’application Hairbnb adopte une architecture de sécurité multicouche basée sur le principe de défense en profondeur.

Cette approche consiste à implémenter plusieurs niveaux de protection indépendants pour garantir qu’une défaillance sur un niveau ne compromette pas la sécurité globale du système.

L’architecture se décompose en quatre couches principales :

Couche de présentation (Frontend) : Interface utilisateur avec contrôles d’accès et validation côté client.
Couche proxy/réseau (Nginx) : Serveur proxy inverse avec protection DDoS, gestion SSL/TLS et filtrage des requêtes.
Couche applicative (Backend) : Serveur de traitement avec authentification, autorisation et logique métier sécurisée.
Couche de données : Base de données avec chiffrement et contrôles d’accès granulaires

Principe de défense en profondeur : Cette stratégie militaire appliquée à l’informatique consiste à multiplier les barrières de sécurité.
Si un attaquant franchit une barrière, il se retrouve face à la suivante.+

2.2. Services tiers intégrés

L’application s’appuie sur plusieurs services externes reconnus pour leur robustesse sécuritaire :

2.2.1. Firebase Authentication (Google)

Aspect	Description
Fonction	Gestion centralisée de l’authentification utilisateur
Avantages sécuritaires	Chiffrement avancé des données d’authentification Support de l’authentification multi-facteurs (2FA) Gestion automatique des sessions utilisateur Protection contre les attaques par force brute
Intégration technique	Tokens JWT (JSON Web Tokens) pour la communication sécurisée entre frontend et backend
Méthodes d’authentification supportées	Email/mot de passe Authentification sociale (Google, Facebook) Authentification par téléphone Comptes anonymes temporaires

Aspect

Description

Fonction

Gestion centralisée de l’authentification utilisateur

Avantages sécuritaires

Chiffrement avancé des données d’authentification
Support de l’authentification multi-facteurs (2FA)
Gestion automatique des sessions utilisateur
Protection contre les attaques par force brute

Intégration technique

Tokens JWT (JSON Web Tokens) pour la communication sécurisée entre frontend et backend

Méthodes d’authentification supportées

Email/mot de passe
Authentification sociale (Google, Facebook)
Authentification par téléphone
Comptes anonymes temporaires

2.2.2. Stripe (Traitement des paiements)

Aspect	Description
Fonction	Gestion sécurisée des transactions financières et des données de paiement
Avantages sécuritaires	Conformité PCI DSS Level 1 (plus haut niveau de sécurité) + Chiffrement des données de carte bancaire (AES-256) + Tokenisation des informations de paiement + Détection automatique des fraudes par machine learning + 3D Secure pour l’authentification renforcée
Intégration technique	API REST sécurisée avec clés d’authentification Webhooks signés pour les notifications de paiement Stripe Elements pour la saisie sécurisée côté client
Protections implémentées	Aucune donnée de carte stockée sur nos serveurs Validation des CVV en temps réel Limitation du taux de tentatives de paiement Monitoring des comportements suspects

Aspect

Description

Fonction

Gestion sécurisée des transactions financières et des données de paiement

Avantages sécuritaires

Conformité PCI DSS Level 1 (plus haut niveau de sécurité)

+ Chiffrement des données de carte bancaire (AES-256)
+ Tokenisation des informations de paiement
+ Détection automatique des fraudes par machine learning
+ 3D Secure pour l’authentification renforcée

Intégration technique

API REST sécurisée avec clés d’authentification
Webhooks signés pour les notifications de paiement
Stripe Elements pour la saisie sécurisée côté client

Protections implémentées

Aucune donnée de carte stockée sur nos serveurs
Validation des CVV en temps réel
Limitation du taux de tentatives de paiement
Monitoring des comportements suspects

2.3. Principes de sécurité appliqués

L’architecture respecte plusieurs principes fondamentaux :

2.3.1. Moindre privilège

Chaque composant et utilisateur dispose uniquement des permissions strictement nécessaires à ses fonctions.

2.3.2. Séparation des responsabilités

Les fonctions critiques sont réparties entre différents modules pour limiter l’impact d’une compromission.

2.3.3. Validation en profondeur

Toute donnée externe est validée à multiples niveaux avant traitement.+

2.3.4. Chiffrement systématique

Les données sensibles sont chiffrées en transit (HTTPS)

Sécurité by Design : Ces principes ont été intégrés dès la conception de l’architecture, conformément aux recommandations du RGPD qui exigent une protection des données dès la conception (Privacy by Design).

3. Sécurité du Frontend Flutter

3.1. Architecture de sécurité mobile et web

L’application Flutter Hairbnb implémente une architecture de sécurité spécifiquement adaptée aux contraintes des plateformes mobiles (Android) et web aussi.

L’approche adopte le pattern Provider pour la gestion d’état centralisée et intègre plusieurs services dédiés à la sécurité.

Pattern Provider - Explication simple : Imaginez une "boîte magique" qui contient toutes les informations importantes de l’app (connexion utilisateur, profil, etc.).

Sans Provider, chaque écran doit chercher les infos tout seul.
Avec Provider, il y a UNE seule boîte et tous les écrans s’y "abonnent".
Quand une info change, TOUS les écrans sont automatiquement au courant.
C’est comme un chef d’orchestre qui synchronise tous les musiciens !

Qu’est-ce qu’un Provider concrètement ?

Un Provider est une classe Dart qui hérite de ChangeNotifier et qui contient :

L’état de l’application (données et variables)
Les méthodes pour modifier cet état (fonctions)
Un système de notification pour prévenir les widgets des changements

Exemple concret dans Hairbnb :

class AuthProvider extends ChangeNotifier {
  User? _currentUser;
  bool _isAuthenticated = false;

  // Getter pour accéder aux données
  User? get currentUser => _currentUser;
  bool get isAuthenticated => _isAuthenticated;

  // Méthode pour se connecter
  Future<void> login(String email, String password) async {
    _currentUser = await FirebaseAuth.signIn(email, password);
    _isAuthenticated = true;
    notifyListeners(); // Dit à tous les écrans : "Hey, ça a changé !"
  }

  // Méthode pour se déconnecter
  void logout() {
    _currentUser = null;
    _isAuthenticated = false;
    notifyListeners(); // Encore une notification !
  }
}

Comment les écrans l’utilisent :

// Dans un écran Flutter
class HomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Consumer<AuthProvider>(
      builder: (context, authProvider, child) {
        if (authProvider.isAuthenticated) {
          return Text('Bonjour ${authProvider.currentUser!.name}');
        } else {
          return Text('Veuillez vous connecter');
        }
      },
    );
  }
}

Le miracle : Quand vous appelez login() depuis l’écran de connexion, la HomePage se met automatiquement à jour pour afficher "Bonjour Soulayman" sans que vous ayez besoin de faire quoi que ce soit !

Avantage sécurité : Une seule source de vérité pour l’état d’authentification.
Impossible d’avoir un écran qui croit que l’utilisateur est connecté et un autre qui croit le contraire.

3.1.1. Structure des services de sécurité

Service Fonction sécuritaire

Service	Fonction sécuritaire
auth_services	Gestion centralisée de l’authentification utilisateur Interface avec Firebase Authentication Validation des identifiants et gestion des erreurs d’auth
firebase_token	Stockage sécurisé des tokens d’authentification Refresh automatique des tokens expirés Chiffrement local des tokens sensibles
routes_services	Protection des routes selon l’état d’authentification Guards de navigation pour les écrans sensibles Redirection automatique vers login si nécessaire
providers	Gestion d’état sécurisée avec `pattern Provider` Synchronisation des données utilisateur en temps réel Nettoyage automatique des données lors de la déconnexion

auth_services

Gestion centralisée de l’authentification utilisateur
Interface avec Firebase Authentication
Validation des identifiants et gestion des erreurs d’auth

firebase_token

Stockage sécurisé des tokens d’authentification
Refresh automatique des tokens expirés
Chiffrement local des tokens sensibles

routes_services

Protection des routes selon l’état d’authentification
Guards de navigation pour les écrans sensibles
Redirection automatique vers login si nécessaire

providers

Gestion d’état sécurisée avec pattern Provider
Synchronisation des données utilisateur en temps réel
Nettoyage automatique des données lors de la déconnexion

3.2. Authentification et gestion des sessions

3.2.1. Intégration Firebase Authentication

L’authentification repose sur Firebase Auth, adaptée spécifiquement pour les contraintes mobiles :

Méthodes d’authentification supportées : - Authentification par email/mot de passe avec validation renforcée - Authentification sociale (Google) - Récupération de mot de passe sécurisée par email

Gestion des tokens : - Stockage dans le Keychain iOS(l’option iOS est non disponible pour cette version) / Android Keystore (via flutter_secure_storage) - Tokens JWT avec refresh automatique - Invalidation immédiate lors de la déconnexion

Figure 1. Authentification Flow

Leçon Flutter : Au début, je ne stockais pas les tokens du tout !
L’utilisateur devait se reconnecter à chaque fois qu’il fermait l’app.
C’était très frustrant côté UX.
Puis j’ai découvert flutter_secure_storage qui permet de stocker les tokens de manière sécurisée en utilisant les keychains natifs des OS mobiles (Keychain iOS / Android Keystore).
Maintenant l’utilisateur reste connecté même après avoir fermé l’app !

3.2.2. Protection des écrans sensibles

Le service routes_services implémente un système de navigation sécurisée :

```dart
// Exemple de guard de route
class AuthGuard {
  static bool canAccess(String route) {
    return AuthProvider.instance.isAuthenticated;
  }
}

Écrans protégés identifiés :

Profil utilisateur et modification des données personnelles.
Tableau de bord coiffeur avec gestion des disponibilités
Paramètres de géolocalisation.

3.3. Sécurité des données géographiques

3.3.1. Service de géolocalisation (Geoapify)

L’intégration du service geoapify_service apporte plusieurs protections :

Aspect sécuritaire	Implementation
Permissions utilisateur	Demande explicite d’autorisation de géolocalisation. Gestion gracieuse du refus de permission. Mode dégradé sans géolocalisation précise.
Protection des données	Limitation de la précision selon le contexte Pas de stockage permanent des coordonnées exactes Anonymisation des données de localisation
Configuration API	Clés API stockées de manière sécurisée Limitation des domaines autorisés Monitoring des appels API pour détecter les abus (option non disponible dans cette version).

Aspect sécuritaire

Implementation

Permissions utilisateur

Demande explicite d’autorisation de géolocalisation.
Gestion gracieuse du refus de permission.
Mode dégradé sans géolocalisation précise.

Protection des données

Limitation de la précision selon le contexte
Pas de stockage permanent des coordonnées exactes
Anonymisation des données de localisation

Configuration API

Clés API stockées de manière sécurisée
Limitation des domaines autorisés
Monitoring des appels API pour détecter les abus (option non disponible dans cette version).

3.4. Gestion sécurisée des liens profonds

Le service deep_link_services traite les liens entrants avec plusieurs vérifications :

Validation des liens :

Whitelist des domaines autorisés
Validation de la structure des paramètres
Protection contre les injections via URL

Cas d’usage sécurisés :

Réinitialisation de mot de passe : Liens générés automatiquement par Firebase Auth avec validation temporelle.
Confirmation de réservation : Liens uniques avec tokens de validation pour confirmer les rendez-vous.
Flux de paiement Stripe : Redirection sécurisée vers Stripe Checkout et retour avec validation du statut de transaction.

Deep linking : Fonctionnalité permettant d’ouvrir directement un écran spécifique de l’app via un lien externe.
Nécessite une validation stricte pour éviter les redirections malveillantes.

3.5. Validation côté client

3.5.1. Validation des formulaires

L’application implémente une validation multi-niveaux pour tous les inputs utilisateur :

Données personnelles :

Validation des formats email avec regex stricte.
Contrôle de robustesse des mots de passe (longueur, complexité)
Sanitisation des caractères spéciaux dans les champs texte
Limitation des tailles de fichier pour les photos de profil

Ecran de création d’adresse non valide

Ecran de création d’un profil

image::img/annexe2.png[Image A, 550, 400, align="center"]

Ecran de création d’un profil non valide	Ecran de création d’un profil valide
Ecran de création d’un profil valide

Ecran de création d’un profil non valide

Ecran de création d’un profil valide

Données de réservation :

Validation des créneaux horaires et cohérence des dates.
Vérification de la disponibilité en temps réel.
Contrôle des durées de prestation selon le type de service.

Ecran de panier	Ecran de plages horaires
Ecran de dates

Ecran de panier

Ecran de plages horaires

Ecran de dates

Validation des créneaux de réservation : Le système implémente une validation stricte côté client en affichant uniquement les créneaux disponibles.
Les créneaux indisponibles sont automatiquement masqués ou désactivés, empêchant ainsi l’utilisateur de sélectionner des horaires conflictuels.
Cette approche proactive élimine les erreurs de saisie et garantit la cohérence des données avant même l’envoi au backend.

3.5.2. Protection contre les injections

Échappement automatique : Flutter échappe automatiquement le contenu dans les widgets Text et RichText, c’est-à-dire qu’il convertit les caractères spéciaux (comme <, >, &, ") en entités sûres pour éviter les injections de code malveillant.

Validation stricte : Tous les inputs sont validés avant envoi au backend via des regex et des contraintes de longueur, c’est-à-dire que chaque champ de formulaire vérifie le format et la taille des données saisies.

Exemple concret dans Hairbnb :

Exemple de validation des formulaires d’authentification

// Validation de l'email
validator: (value) {
  if (value == null || value.isEmpty) {
    return 'Veuillez saisir votre email';
  }
  final emailRegex = RegExp(r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$');
  if (!emailRegex.hasMatch(value)) {
    return 'Format d\'email invalide';
  }
  return null;
},

// Validation du mot de passe
validator: (value) {
  if (value == null || value.length < 8) {
    return 'Le mot de passe doit contenir au moins 8 caractères';
  }
  if (!RegExp(r'^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)').hasMatch(value)) {
    return 'Le mot de passe doit contenir une majuscule, une minuscule et un chiffre';
  }
  return null;
},

Apprentissage par l’erreur : J’ai d’abord fait confiance à la validation côté serveur uniquement.

Mais l’ajout de la validation côté client améliore l’expérience utilisateur et constitue une première barrière de sécurité.

3.6. Communication sécurisée avec l’API

3.6.1. Configuration des requêtes HTTP

dartclass APIService { static const String baseURL = 'https://api.hairbnb.com';

  static Map<String, String> get headers => {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer ${TokenService.getToken()}',
    'X-App-Version': PackageInfo.version,
  };
}

Protections implémentées :

Protections implémentées :

Headers d’authentification automatique, c’est-à-dire que chaque requête vers le serveur inclut automatiquement la "carte d’identité" de l’utilisateur sans qu’il ait besoin de la ressaisir à chaque fois.
Gestion sécurisée des erreurs de réseau, c’est-à-dire que quand quelque chose ne se passe mal (pas d’internet, serveur en panne, etc.), l’application affiche des messages clairs à l’utilisateur au lieu de montrer des codes d’erreur techniques incompréhensibles.

3.6.2. Gestion des erreurs et logs

Logging sécurisé :

Protections des données et monitoring :

Aucune donnée sensible dans les logs de production, c’est-à-dire que quand l’application fonctionne chez les vrais utilisateurs, elle n’enregistre jamais d’informations personnelles (mots de passe, emails, numéros de téléphone) dans ses fichiers de suivi.
Hashage des identifiants dans les logs de debug, c’est-à-dire que même pendant le développement, les données des utilisateurs sont transformées en codes illisibles pour protéger leur identité si un développeur consulte les logs.
Monitoring des tentatives d’accès non autorisées, c’est-à-dire que l’application surveille et détecte automatiquement quand quelqu’un essaie de se connecter sans autorisation ou d’accéder à des données qui ne lui appartiennent pas.

Gestion des erreurs et sécurité utilisateur :

Messages génériques pour l’utilisateur final, c’est-à-dire que quand quelque chose ne fonctionne pas, l’application montre de simples messages rassurants comme "Problème de connexion" au lieu d’afficher des détails techniques effrayants.
Logs détaillés pour le débogage (hors production), c’est-à-dire que pendant le développement de l’application, les programmeurs peuvent voir tous les détails techniques pour corriger les bugs, mais ces informations ne sont jamais visibles quand l’app est utilisée par de vrais clients.

Figure 2. Des logs de la partie front-end (Flutter)

Redirection vers des écrans sûrs en cas d’erreur critique, c’est-à-dire que si l’application rencontre un problème grave, elle redirige automatiquement l’utilisateur vers une page sécurisée (comme l’écran d’accueil) plutôt que de le laisser sur un écran cassé ou dangereux.

3.7. Sécurité spécifique aux plateformes mobiles

3.7.1. Protection au niveau système

Protections spécifiques par plateforme :

Android : * Obfuscation du code avec ProGuard/R8, c’est-à-dire que le code de l’application est rendu illisible pour empêcher les pirates de comprendre comment elle fonctionne en l’analysant.

Web : * Protection contre les extensions malveillantes, c’est-à-dire que l’application web détecte et bloque les extensions de navigateur qui pourraient voler des données ou modifier le comportement de l’app.

Aucun stockage, c’est-à-dire que toutes les données disparaissent dès que l’utilisateur ferme l’onglet ou le navigateur.
HTTPS obligatoire et sécurité navigateur renforcée, c’est-à-dire que toutes les communications sont automatiquement chiffrées et que l’application refuse de fonctionner si la connexion n’est pas sécurisée.

3.7.2. Gestion des permissions

L’application suit le principe du moindre privilège pour les permissions système :

Géolocalisation : Demandée uniquement lors de la recherche de coiffeurs Stockage : Accès limité aux photos de profil Réseau : Restriction aux domaines Hairbnb et services tiers autorisés.

Pour être honnête, je n’ai pas implémenté toutes ces fonctionnalités manuellement.
Une grande partie de ces protections, ainsi que d’autres non mentionnées dans cette section, sont intégrées par défaut dans Flutter.
C’est d’ailleurs l’un des points forts majeurs de ce framework : il est conçu pour faciliter au maximum l’implémentation des fonctionnalités que souhaite un développeur, en fournissant des solutions de sécurité robustes dès l’installation.

— Points forts du développement Flutter

4. Infrastructure et reverse proxy

L’infrastructure de sécurité de l’application HairBnB repose sur une configuration Nginx robuste agissant comme reverse proxy entre le domaine public hairbnb.

Le Site et l’application Django hébergée localement.

Cette couche intermédiaire constitue la première ligne de défense contre les cyberattaques, implémentant des mécanismes de protection avancés incluant le chiffrement SSL/TLS, le rate limiting, et le blocage proactif des tentatives d’intrusion.

L’analyse des logs de sécurité révèle une efficacité remarquable avec plus de 100 tentatives d’attaques malveillantes détectées et neutralisées automatiquement.

4.1. Architecture du reverse proxy

4.1.1. Configuration générale

L’architecture Nginx implémente une sécurité multicouche avec redirection systématique et proxy transparent vers l’application backend.

La redirection HTTP→HTTPS automatique garantit que toutes les communications sont chiffrées, même si l’utilisateur tape une URL non sécurisée.

Figure 3. Flux NGINX Simplifié

Redirection HTTP vers HTTPS systématique

server {
# ← Écoute sur port HTTP
    listen 80;
    server_name hairbnb.site www.hairbnb.site;
# ← Redirection FORCÉE vers HTTPS
    return 301 https://$host$request_uri;
}

Proxy principal vers l’application Django

# Ce bloc de configuration s'applique à toutes les requêtes entrantes,
# car "/" est la racine de toutes les URL.
location / {

    # Transfère la requête au serveur d'application qui écoute sur le port 8080
    # de la machine locale (localhost). C'est le cœur du reverse proxy.

    proxy_pass http://127.0.0.1:8080;

    # Passe le nom de domaine original "hairbnb.site" demandé par le client
    # au serveur d'application. Essentiel pour les serveurs hébergeant plusieurs sites.

    proxy_set_header Host $host;

    # Ajoute un en-tête "X-Real-IP" contenant l'adresse IP réelle du visiteur.
    # Sans cela, l'application ne verrait que l'IP du proxy Nginx.

    proxy_set_header X-Real-IP $remote_addr;

    # Ajoute l'IP du visiteur à l'en-tête "X-Forwarded-For". Cet en-tête
    # est la méthode standard pour tracer les IP successives lors du passage
    # à travers plusieurs proxys.

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # Informe le serveur d'application que la connexion initiale entre le client et
    # Nginx a été faite en HTTPS. Crucial si Nginx gère le chiffrement SSL/TLS.

    proxy_set_header X-Forwarded-Proto https;
}

4.2. Gestion SSL/TLS sécurisée

La configuration SSL utilise uniquement les protocoles TLS 1.2 et 1.3, excluant les versions obsolètes et vulnérables.

Certificats SSL configurés :

Certificat principal : C:/nginx/ssl/hairbnb/certificate.crt
Clé privée : C:/nginx/ssl/hairbnb/private.key
Bundle CA : C:/nginx/ssl/hairbnb/ca_bundle.crt

Protocoles et chiffrement renforcés

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;

4.3. Qu’est-ce que SSL/TLS ?

SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont des protocoles de chiffrement qui sécurisent les communications sur Internet.

TLS = Version moderne et sécurisée de SSL

SSL = Ancienne version (obsolète, mais le terme reste utilisé)

En pratique : C’est ce qui transforme http:// en https:// (le 's' = secure)

4.3.1. À quoi ça sert concrètement ?

Table 1. Comparaison HTTP vs HTTPS
Sans SSL/TLS (HTTP)	Avec SSL/TLS (HTTPS)
Données en clair	Données chiffrées
N’importe qui peut lire	Impossible à déchiffrer
Pas d’authentification	Serveur authentifié
Vulnérable aux attaques	Communications protégées

4.3.2. Exemple concret

Table 2. Comparaison détaillée : Transmission d’un mot de passe
Étape	Sans SSL/TLS (HTTP)	Avec SSL/TLS (HTTPS)
Saisie utilisateur	"monmotdepasse123"	"monmotdepasse123"
Transmission sur Internet	Transmis tel quel en clair	Chiffré en "Kj8#mP9$xL2@vN5…"
Si interception par un pirate	Peut lire : "monmotdepasse123"	Voit seulement : "Kj8#mP9$xL2@vN5…"
Résultat sécurité	Mot de passe compromis	Impossible à déchiffrer sans la clé

4.3.3. Qu’est-ce qu’un certificat SSL/TLS ?

Définition simple

Un certificat SSL/TLS est comme une "carte d’identité électronique" qui prouve que votre site web est légitime et permet le chiffrement.

4.3.4. Contenu d’un certificat

CERTIFICAT SSL/TLS

Nom du domaine : hairbnb.site
Propriétaire : [Votre organisation]
Clé publique : [Pour le chiffrement]
Validité : Du 01/01/2025 au 01/01/2026
Signature : [Autorité de certification]
Empreinte : [Hash unique]

Table 3. Les 3 rôles détaillés du certificat SSL/TLS
Rôle	Problème résolu	Explication concrète	Exemple pratique
CHIFFREMENT	Les données circulent en clair sur Internet	Le certificat contient une clé publique qui permet de chiffrer toutes les communications entre votre navigateur et le serveur	Votre mot de passe "secret123" devient "X8k#mP2@vL9…" pendant le transport
AUTHENTIFICATION	Comment savoir si on parle au vrai serveur ?	Le certificat prouve l’identité du serveur. Il est signé par une autorité de certification qui garantit que ce serveur appartient bien au domaine indiqué	Quand vous allez sur hairbnb.site, le certificat prouve que vous parlez bien au serveur de HairBnB et non à un site malveillant qui imite le vrai
INTÉGRITÉ	Les données peuvent être modifiées en route	Le certificat permet de vérifier que les données reçues sont exactement les mêmes que celles envoyées, sans modification	Si un pirate essaie de modifier votre commande de 50€ en 500€, le système détecte la modification et rejette la transaction

4.3.5. Comment ça fonctionne ?

Processus d’établissement SSL/TLS

4.3.6. Types de certificats SSL/TLS

4.4. Par niveau de validation

Table 4. Types de validation des certificats
Type	Validation	Exemple	Usage
DV	Domaine uniquement	Let’s Encrypt	Sites personnels
OV	Organisation vérifiée	Certificats payants	Sites d’entreprise
EV	Validation étendue	Banques	Sites critiques

4.5. Par couverture

Table 5. Couverture des certificats
Type	Couvre	Exemple
Single Domain	Un seul domaine	hairbnb.site
Wildcard	Domaine + sous-domaines	*.hairbnb.site
Multi-Domain	Plusieurs domaines	hairbnb.site + hairbnb.com

4.6. Sécurité et protection contre les attaques

4.6.1. Rate Limiting

Sans rate limiting, un attaquant pourrait saturer le serveur avec des milliers de requêtes simultanées.

Protection contre les attaques par déni de service

# Définit une zone de mémoire partagée pour la limitation de requêtes.
# - Clé de limitation : L'adresse IP du client ($binary_remote_addr).
# - Nom de la zone : "mylimit".
# - Taille de la zone : 10 mégaoctets.
# - Taux maximum autorisé : 5 requêtes par seconde par IP.

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

# Applique la limitation définie dans la zone "mylimit".
# - burst=10 : Autorise un pic de 10 requêtes au-delà du taux défini.
# - nodelay : Traite les requêtes du "burst" sans les ralentir. Toute requête
#   dépassant le taux + le burst est immédiatement rejetée (avec une erreur 503).

limit_req zone=mylimit burst=10 nodelay;

4.7. Headers de sécurité

La configuration implémente tous les headers de sécurité modernes recommandés par l’OWASP.

Configuration complète des en-têtes de protection

# Force l'utilisation de HTTPS pour une durée de 2 ans sur ce domaine et tous ses
# sous-domaines, et permet l'inclusion dans les listes de préchargement des navigateurs.

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Contrôle les informations envoyées dans l'en-tête "Referer".
# L'URL complète est envoyée pour les requêtes sur la même origine, mais seulement
# l'origine (domaine) pour les requêtes vers d'autres sites.
add_header Referrer-Policy "strict-origin-when-cross-origin";

# Empêche la page d'être affichée dans une <frame> ou <iframe> (protection clickjacking).

add_header X-Frame-Options "DENY";

# Empêche le navigateur d'essayer de deviner le type MIME d'un fichier,
# forçant le respect du "Content-Type" déclaré par le serveur.
add_header X-Content-Type-Options "nosniff";

# Active le filtre XSS des navigateurs (principalement pour la compatibilité)

# et bloque le rendu de la page si une attaque est détectée.

add_header X-XSS-Protection "1; mode=block";

4.8. Protection contre les chemins malveillants

L’analyse des logs suspicious.log révèle une protection efficace contre les attaques automatisées les plus courantes.

Table 6. Analyse des logs suspicious.log - Attaques détectées et bloquées
Type d’attaque	Nombre de tentatives	IPs uniques	Statut
Accès `.git/config`	45+ tentatives	15+ IPs	✅ Bloqué (444)
Fichiers `.env`	20+ tentatives	8+ IPs	✅ Bloqué (444)
WordPress scan	15+ tentatives	10+ IPs	✅ Bloqué (444)
Dossiers backup	25+ tentatives	6+ IPs	✅ Bloqué (444)

Figure 4. Configuration de blocage

Exemples d’attaques bloquées (extraits des logs)

31.153.23.149 - "GET /.git/config HTTP/1.1" 444 0
154.83.103.207 - "GET /.env.production HTTP/1.1" 444 0
68.183.236.23 - "GET /wp-admin/setup-config.php" 444 0
135.119.141.8 - "HEAD /backup HTTP/1.1" 444 0

Le code de réponse 444 est spécifique à Nginx et ferme la connexion sans envoyer de réponse, économisant les ressources serveur.

Configuration de blocage implémentée

# Blocage des chemins suspects
location ~* ^/(wp-admin|wp-login|wp-content|wp-includes|joomla|drupal|typo3|xmlrpc\.php|backup|\.env|\.git|\.ssh|\.bash_history|\.DS_Store|\.htaccess|\.htpasswd|config|settings\.py|\.sql|\.bak|\.old|\.log|main|home|docker|swagger|actuator|metrics) {
    return 444;
}

# Blocage des User-Agents malveillants
if ($http_user_agent ~* (HTTrack|Wget|curl|python|scrapy|libwww-perl|ApacheBench)) {
    return 444;
}

4.9. Surveillance et logging

Logs d’accès normaux (paste.txt) :

Trafic légitime de l’application Flutter
Authentification Firebase avec JWT valides
Requêtes API géolocalisées pour les salons
Codes de réponse 200/301 attendus

Logs d’erreur détaillés :

Traçage complet des requêtes SSL
Monitoring des connexions proxy
Validation des headers de sécurité appliqués

4.10. Liaison domaine vers serveur local

4.10.1. Configuration DNS

Le domaine hairbnb.site est configuré pour pointer vers l’IP publique 91.86.52.162(l’IP publique de ma connexion Internet domestique), permettant une liaison transparente entre le domaine externe et le serveur local.

4.11. Gestion des fichiers statiques

Fichiers media avec CORS configuré

# Ce bloc de configuration s'applique à toutes les requêtes commençant par /media/
location /media/ {

    # Définit le dossier racine sur le serveur où Nginx trouvera les fichiers.
    # Pour une requête /media/image.png, le fichier sera cherché dans
    # C:/Users/Admin/PycharmProjects/hairbnb_backend/media/image.png

    root C:/Users/Admin/PycharmProjects/hairbnb_backend/;

    # Si un répertoire est demandé, affiche automatiquement la liste des fichiers
    # qu'il contient (s'il n'y a pas de fichier index.html).
    autoindex on;

    # Indique au navigateur de mettre en cache ces fichiers pour la durée la plus longue
    # possible afin d'optimiser les chargements futurs.

    expires max;

    # Désactive l'écriture de ces requêtes dans les logs d'accès pour
    # réduire l'utilisation du disque.

    access_log off;

    # Autorise les requêtes provenant d'une liste des noms de domaines définis (CORS)
    # à accéder à ces ressources.

    add_header Access-Control-Allow-Origin $cors_origin;;
}

Fichiers statiques optimisés

location /static/ {
    alias C:/Users/Admin/PycharmProjects/hairbnb_backend/staticfiles/;
    autoindex on;
    expires max;
    access_log off;
}

4.12. Analyse des performances et fiabilité

4.12.1. Métriques de sécurité observées

L’efficacité de 100% dans le blocage des attaques démontre une configuration de sécurité robuste et bien calibrée.

Efficacité du blocage :

100% des attaques bloquées avec code 444
Zéro faille exploitée selon les logs ( enfin j’espère !)
Rate limiting fonctionnel (pas de dépassement observé)

Trafic légitime observé

127.0.0.1 - "GET /api/get_current_user/" 200 503
127.0.0.1 - "POST /api/add_to_cart/" 200 679
127.0.0.1 - "GET /api/salons-proches-public/" 200 2529

5. La sécurité du backend

5.1. Le backend : Le cerveau de HairBnB

Le backend Django de HairBnB agit comme le "cerveau" de l’application.

Contrairement au frontend que les utilisateurs voient et touchent, le backend travaille en coulisses pour traiter toutes les demandes et gérer les données sensibles.

"Si le frontend est la vitrine d’un magasin, le backend est le coffre-fort, la comptabilité et le système de sécurité combinés."

— trouvé sur internet

5.2. Rôle et responsabilités du backend

Table 7. Comparaison Frontend vs Backend
Aspect	Frontend (Flutter)	Backend (Django)
Rôle principal	Interface utilisateur	Traitement et sécurité des données
Visible par l’utilisateur	Oui (écrans, boutons)	Non (travaille en arrière-plan)
Responsabilités	Affichage, navigation, validation de base	Authentification, base de données, logique métier
Confiance	Ne jamais faire confiance	Validation et vérification de tout
Exemple concret	Formulaire de réservation	Vérification de disponibilité réelle

Figure 5. Architecture Backend HairBnB

5.3. Enjeux critiques de sécurité

Dans une application comme HairBnB, la sécurité backend est critique car nous manipulons des données extrêmement sensibles.

5.3.1. Classification des données par niveau de sensibilité

Table 8. Données sensibles gérées par le backend
Niveau de criticité	Type de données	Exemples concrets	Impact si compromis
🟠 ÉLEVÉ	Données personnelles	Adresses domicile, téléphones	Usurpation d’identité, cambriolage
🟡 MOYEN	Données de géolocalisation	Positions GPS, trajets	Harcèlement, atteinte vie privée
🟢 FAIBLE	Données publiques	Avis, photos de profil	Réputation, image

5.3.2. Menaces spécifiques au métier

Figure 6. Menaces ciblant les plateformes de services

5.4. Principe de "Confiance Zéro"

La sécurité du backend HairBnB repose sur le principe fondamental de "Zero Trust" ou "Confiance Zéro".

Principe de base : "Ne jamais faire confiance, toujours vérifier"

Même si une requête semble provenir d’un utilisateur légitime, le backend vérifie TOUT avant d’autoriser quoi que ce soit.

5.4.1. Mise en pratique du principe "Confiance Zéro"

Table 9. Application du principe "Zero Trust" dans HairBnB
Situation	❌ Approche "Confiance"	✅ Approche "Zero Trust"
Utilisateur connecté	"Il est connecté, donc OK"	"Qui est-il ? Token valide ? Permissions ?"
Modification de profil	"C’est son profil, il peut modifier"	"Est-ce vraiment son profil ? A-t-il le droit ?"
Réservation	"Le créneau semble libre"	"Vérification en temps réel de la disponibilité"
Paiement	"La carte semble valide"	"Validation Stripe + vérification fraude"

Figure 7. Processus de validation "Zero Trust"

5.4.2. Exemple concret : Réservation d’un rendez-vous

Prenons l’exemple d’une réservation pour illustrer le principe "Zero Trust" :

Figure 8. Processus de réservation sécurisée

5.4.3. Bénéfices de cette approche

Cette approche "Zero Trust" du backend HairBnB offre plusieurs avantages :

Table 10. Avantages de la sécurité "Zero Trust"
Avantage	Explication	Exemple concret
Protection multicouche	Plusieurs points de contrôle	Si un filtre échoue, les autres protègent
Traçabilité complète	Tout est enregistré et analysé	En cas de problème, on peut retracer l’origine
Détection précoce	Les anomalies sont détectées rapidement	Tentative de piratage bloquée immédiatement

Retour d’expérience personnel Cette approche de sécurité rigoureuse peut parfois sembler "lourde", mais elle est le fruit d’un apprentissage progressif et parfois difficile.

"Je dois être honnête : cette architecture sécurisée que je présente aujourd’hui n’existait pas dès le début.
Au commencement du projet, ma connaissance des risques de sécurité était bien plus limitée qu’aujourd’hui.
Cette expertise s’est construite à travers :
- Les enseignements de ma formation en informatique de gestion.
- Mon autoformation continue sur la cybersécurité.
- Les recherches intensives quand je tombais sur des problèmes concrets.
- Les multiples restructurations du code quand je découvrais de nouveaux risques.
J’ai dû revenir plusieurs fois sur certaines parties pour les renforcer, parfois complètement les refaire.
C’est un processus d’amélioration continue qui m’a appris que la sécurité n’est jamais acquise - elle se construit, se teste et s’améliore en permanence.
J’espère sincèrement qu’il ne reste pas de maillons faibles dans cette chaîne de sécurité, mais je sais que c’est un domaine où l’apprentissage ne s’arrête jamais."

— Réflexion sur mon parcours de développement

Je pense que cette démarche d’amélioration continue est la clé d’une sécurité efficace : reconnaître ses limites, apprendre de ses erreurs et renforcer constamment ses défenses.

5.5. Système d’authentification et d’autorisation

5.5.1. Authentification Firebase côté Backend

Nous avons déjà évoqué Firebase Authentication dans les sections précédentes, mais il est important de comprendre que le backend Django a sa propre logique de vérification, indépendante du frontend.

Pourquoi reparler de Firebase Auth ?

Ce n’est pas de la redondance !
Le backend vérifie lui-même l’authenticité des tokens Firebase grâce à :
- La dépendance Firebase Admin SDK pour Python.
- La clé API privée (firebase_credentials.json).
- Sa propre logique de validation indépendante du frontend.

5.5.2. Différence Frontend vs Backend pour Firebase

Table 11. Rôles Firebase selon la couche
Aspect	Frontend Flutter	Backend Django
Rôle Firebase	Connexion utilisateur	Vérification des tokens
Dépendance	Firebase Auth SDK	Firebase Admin SDK
Fichier de config	`google-services.json`	`firebase_credentials.json`
Logique	"Je me connecte"	"Je vérifie qui tu es vraiment"
Confiance	Peut être compromis	Source de vérité absolue

Figure 9. Flux d’authentification Firebase complet

5.6. Les "Décorateurs" - Gardiens intelligents

Les décorateurs sont comme des "videurs de boîte de nuit" intelligents placés devant chaque fonction sensible du backend.
Ils vérifient les autorisations avant de laisser passer.

"Un décorateur, c’est comme un garde du corps qui pose toujours les mêmes questions : 'Qui êtes-vous ?', 'Avez-vous le droit d’être ici ?' et 'Que voulez-vous faire exactement ?'"

— trouvé sur internet

5.6.1. Architecture des décorateurs dans HairBnB

Figure 10. Système de décorateurs en cascade

Le schema est un exemple pour donner une idée, mais il ne couvre pas toutes les fonctionnalités

`@firebase_authenticated` - "Êtes-vous bien connecté ?"

C’est le décorateur de base qui vérifie l’identité de l’utilisateur.

@firebase_authenticated
def ma_fonction_protegee(request):
    # Cette fonction ne s'exécute QUE si l'utilisateur
    # est authentifié via Firebase
    pass

Table 12. Contrôles effectués par @firebase_authenticated
Vérification	Question posée	Réponse si échec
Token présent ?	"Avez-vous votre 'carte d’identité' numérique ?"	❌ 401 Unauthorized
Token valide ?	"Cette carte n’est-elle pas expirée ou falsifiée ?"	❌ 401 Unauthorized
Utilisateur existe ?	"Êtes-vous bien enregistré dans notre système ?"	❌ 404 User Not Found

Figure 11. Processus de vérification @firebase_authenticated

`@is_owner` - "Ces données vous appartiennent-elles ?"

Ce décorateur vérifie que l’utilisateur ne peut accéder qu’à SES propres données.

@is_owner(param_name="idTblUser")
def modifier_profil(request, idTblUser):
    # Marie (ID=123) ne peut modifier que le profil ID=123
    # Si elle essaie de modifier le profil ID=456, accès refusé !
    pass

Table 13. Cas d’utilisation du décorateur @is_owner
Situation	Sans protection	Avec @is_owner	Résultat
Marie modifie son profil	Accès libre à tous les profils	Vérification ID utilisateur	✅ Autorisé
Marie tente de modifier le profil de Sophie	Modification possible !	Blocage automatique	❌ Refusé (403 Forbidden)
Requête avec ID manquant	Erreur imprévisible	Contrôle du paramètre	❌ Refusé (400 Bad Request)

Figure 12. Fonctionnement @is_owner

`@is_owner_coiffeuse` - "Êtes-vous bien propriétaire de salon ?"

Ce décorateur spécialisé vérifie que l’utilisateur est une coiffeuse ET propriétaire d’un salon.

Table 14. Contrôles spécifiques d'@is_owner_coiffeuse
Vérification	Explication	Base de données consultée
Type utilisateur	Est-ce une coiffeuse ?	`TblUser.type_ref = 'Coiffeuse'`
Profil coiffeuse	Profil coiffeuse existe-t-il ?	`TblCoiffeuse` avec `idTblUser`
Propriété salon	Est-elle propriétaire d’un salon ?	`TblCoiffeuseSalon.est_proprietaire = True`

Figure 13. Processus de vérification propriétaire salon

5.7. Exemple concret : Gestion des revenus

Prenons l’exemple d’une coiffeuse qui veut consulter ses revenus :

Figure 14. Cas d’utilisation : Consultation des revenus

5.8. Avantages des décorateurs

Table 15. Bénéfices de l’utilisation des décorateurs
Avantage	Explication	Impact sécurité
Réutilisabilité	Un décorateur protège plusieurs fonctions	Sécurité cohérente partout
Lisibilité	Le code montre clairement les protections	Moins de risques d’oubli
Maintenance	Modification centralisée de la sécurité	Évolution facile des règles
Performance	Vérifications optimisées et mises en cache	Réponse rapide même avec sécurité

"Je connaissais déjà cette notion des décorateurs grâce à Java, où on les appelle des 'annotations'.
Dans Java et certains autres langages, j’avais déjà pu constater à quel point ces outils sont puissants et peuvent donner des résultats très efficaces.
Les décorateurs ne se limitent pas seulement à la sécurité - ils sont utiles pour le logging, la mise en cache, la gestion des transactions, la validation des données, et bien d’autres aspects.
Mais je trouve que dans le domaine de la sécurité, ils ont un rôle particulièrement déterminant et puissant.
Ce qui m’a le plus marqué, c’est leur capacité à centraliser la logique de sécurité.
Au lieu d’avoir du code de vérification éparpillé partout, on peut protéger une fonction entière avec une simple ligne : @firebase_authenticated ou @is_owner.
C’est élégant, réutilisable et surtout, difficile à oublier.
D’ailleurs, au début du développement, j’avais oublié certains décorateurs sur des fonctions sensibles.
C’est en testant l’application que j’ai réalisé qu’un utilisateur pouvait accéder aux données d’un autre !
Cette erreur m’a définitivement convaincu de l’importance des décorateurs pour une sécurité design. +

— Réflexion personnelle sur les décorateurs/annotations

5.9. Les Middlewares - Filtres de sécurité

5.9.1. Qu’est-ce qu’un Middleware ?

Un middleware est comme un "filteur" ou un "contrôleur" qui intercepte TOUTES les requêtes avant qu’elles n’atteignent votre application Django.

"Imaginez un middleware comme un agent de sécurité à l’entrée d’un bâtiment qui vérifie systématiquement chaque visiteur avant de le laisser entrer.
Contrairement aux décorateurs qui protègent des fonctions spécifiques, les middlewares examinent TOUT le trafic entrant."

5.9.2. Différence Middleware vs Décorateur

Table 16. Middleware vs Décorateur - Comparaison
Aspect	Middleware	Décorateur
Portée	Toutes les requêtes de l’application	Fonctions spécifiques choisies
Position	Avant même que Django traite la requête	Juste avant l’exécution de la fonction
Analogie	Contrôle douanier à l’aéroport	Videur devant une salle VIP
Usage typique	Sécurité globale, logging, CORS	Autorisation spécifique
Ordre d’exécution	Premier filtre rencontré	Après routage Django

Figure 15. Architecture des Middlewares dans Django

5.10. Filtre géographique - Protection par pays

Le middleware CountryRestrictionMiddleware utilise la géolocalisation par IP pour bloquer les connexions provenant de pays non autorisés.

5.10.1. Principe de fonctionnement

Table 17. Géolocalisation par IP - Comment ça marche ?
Étape	Action	Exemple concret
1. Extraction IP	Récupération de l’adresse IP du visiteur	91.86.52.162 (mon IP publique)
2. Géolocalisation	Consultation base GeoLite2	91.86.52.162 → Belgique (BE)
3. Vérification	Comparaison avec pays autorisés	BE ∈ [BE] → Autorisé
4. Décision	Autorisation ou blocage	Accès accordé ou erreur 403

Figure 16. Processus de filtrage géographique

5.11. Configuration du filtrage géographique

Liste des IP autorisées (bypass géolocalisation)
ALLOWED_IPS = ['127.0.0.1', 'localhost', '::1', '91.86.52.162']
Seule la Belgique est autorisée
if country != 'BE':
logger.info(f"Blocked country: {country}", extra={'ip': ip})
return HttpResponseForbidden("Access Denied.")

Table 18. Avantages du filtrage géographique
Avantage	Explication	Impact sécurité
Réduction du trafic malveillant	90% des attaques viennent de pays spécifiques	Diminution drastique des tentatives
Protection automatique	Aucune intervention manuelle nécessaire	Sécurité 24h/24 même la nuit
Logging intégré	Traçabilité des tentatives bloquées	Analyse des patterns d’attaque
Performance	Blocage avant traitement Django	Économie de ressources serveur

5.11.1. Blocage des requêtes malveillantes

Le middleware BlockMaliciousRequestsMiddleware détecte et bloque les tentatives de piratage automatisées.

Types d’attaques détectées

Table 19. Catalogue des attaques courantes bloquées
Type d’attaque	Chemin typique	Objectif de l’attaquant	Action HairBnB
SonicWall Exploit	/sslvpnLogin.html	Exploitation de VPN d’entreprise	❌ Blocage immédiat
API Sonicos	/api/sonicos/auth	Accès non autorisé systèmes réseau	❌ Blocage immédiat
Auth Bypass	/auth.html, /auth1.html	Contournement authentification	❌ Blocage immédiat
WS-Management	/wsman	Gestion à distance Windows	❌ Blocage immédiat

Figure 17. Détection et blocage des requêtes malveillantes

5.11.2. Efficacité du blocage

Selon l’analyse des logs suspicious.log mentionnée dans le rapport Nginx : .Statistiques de blocage (extrait logs)

Type d’attaque

Tentatives détectées

IPs uniques

Efficacité

Accès .git/config

45+ tentatives

15+ IPs différentes

✅ 100% bloquées

Fichiers .env

20+ tentatives

8+ IPs différentes

✅ 100% bloquées

Scans WordPress

15+ tentatives

10+ IPs différentes

✅ 100% bloquées

Tentatives backup

25+ tentatives

6+ IPs différentes

✅ 100% bloquées

5.12. Protection CSRF

5.12.1. Qu’est-ce que le CSRF ?

CSRF signifie "Cross-Site Request Forgery" ou "Falsification de requête inter-sites".

Le CSRF expliqué simplement : Imaginez que vous êtes connecté à votre banque en ligne.
Un site malveillant pourrait essayer de faire des virements depuis votre compte en profitant que vous êtes connecté, sans que vous le sachiez ! Le CSRF, c’est exactement ça : un site malveillant qui abuse de votre connexion sur un autre site pour effectuer des actions non autorisées.

Figure 18. Attaque CSRF - Scénario type

5.12.2. Protection CSRF dans HairBnB

Django inclut une protection CSRF native, mais HairBnB utilise un middleware personnalisé BypassCSRFMiddleware pour gérer les API.

Table 20. Stratégie de protection CSRF
Type de requête	Protection appliquée	Raison
Pages web Django	CSRF token obligatoire	Protection formulaires HTML
API REST (authentifiées)	Bypass CSRF + vérification Firebase	API ne utilisent pas de cookies de session
Requêtes non authentifiées	CSRF standard	Protection contre attaques génériques

Figure 19. Protection CSRF dans l’architecture HairBnB

5.12.3. Exemple concret : Tentative CSRF sur HairBnB

Supposons qu’un site malveillant tente de créer une réservation à l’insu de Maggie.

Figure 20. Tentative d’attaque CSRF sur HairBnB

5.12.4. Ordre d’exécution des Middlewares

L’ordre des middlewares dans Django est crucial, car ils s’exécutent séquentiellement.

Configuration des middlewares HairBnB (settings.py)

MIDDLEWARE = [
'hairbnb_backend.middlewares.BlockWordPressScannersMiddleware',  # 1
'corsheaders.middleware.CorsMiddleware',                        # 2
'django.middleware.security.SecurityMiddleware',                # 3
'django.contrib.sessions.middleware.SessionMiddleware',         # 4
'django.middleware.csrf.CsrfViewMiddleware',                   # 5
'middleware.country_restriction.CountryRestrictionMiddleware',  # 6
'middleware.firebase_auth_middleware.FirebaseAuthMiddleware',   # 7
'middleware.bypass_csrf_middleware.BypassCSRFMiddleware',       # 8
'middleware.block_malicious_requests_middleware.BlockMaliciousRequestsMiddleware', # 9
]

Figure 21. Chaîne de traitement des middlewares

5.12.5. Efficacité globale du système de middlewares

Table 21. Bilan de performance des middlewares
Middleware	Requêtes filtrées	Efficacité	Impact performance
Géographique	~60% du trafic bloqué	Très élevée	Négligeable (blocage précoce)
Malveillant	100+ tentatives/jour	100% de détection	Aucun (requête arrêtée immédiatement)
CSRF	Prévention, pas de blocage mesurable	Protection continue	Minime
Firebase	Gestion authentification	Validation réussie	Acceptable (mise en cache)

Leçon apprise : L’ordre compte !
Au début, j’avais mal ordonné mes middlewares.
Le filtre géographique était placé après l’authentification Firebase, ce qui était inefficace : pourquoi authentifier un utilisateur qu’on va bloquer ensuite ?
Maintenant, les filtres les plus "éliminateurs" (géographie, patterns malveillants) sont placés en premier pour économiser les ressources sur les requêtes légitimes.

5.13. Configuration de sécurité avancée

5.13.1. Restrictions d’accès

Liste blanche des domaines autorisés

Django utilise ALLOWED_HOSTS pour contrôler strictement quels domaines peuvent servir l’application.

Configuration ALLOWED_HOSTS dans HairBnB

# settings_test.py
ALLOWED_HOSTS = ['hairbnb.site', 'www.hairbnb.site']

Table 22. Contrôle d’accès par domaine
Domaine testé	Résultat	Raison
`hairbnb.site`	✅ Autorisé	Domaine principal configuré
`www.hairbnb.site`	✅ Autorisé	Sous-domaine www autorisé
`fake-hairbnb.com`	❌ Refusé	Domaine non autorisé
`127.0.0.1` (dev)	❌ Refusé en production	Sécurité production

5.13.2. Configuration HTTPS obligatoire

# Redirection automatique vers HTTPS
SECURE_SSL_REDIRECT = True
SESSION_COOKIE_SECURE = True  # Cookies uniquement en HTTPS
CSRF_COOKIE_SECURE = True     # Token CSRF uniquement en HTTPS

5.13.3. Headers de sécurité renforcés

Table 23. Headers de sécurité configurés
Header	Valeur	Protection
`X_FRAME_OPTIONS`	`DENY`	Anti-clickjacking
`SECURE_CONTENT_TYPE_NOSNIFF`	`True`	Anti-MIME sniffing
`SECURE_BROWSER_XSS_FILTER`	`True`	Filtrage XSS navigateur

====Validation des données

Contrôle strict des mots de passe

AUTH_PASSWORD_VALIDATORS = [
    {'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator'},
    {'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator'},
    {'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator'},
    {'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator'},
]

Table 24. Règles de validation des mots de passe
Validateur	Règle appliquée	Exemple refusé
Similarité	Pas trop similaire au nom d’utilisateur	`marie123` pour Marie Dupont
Longueur	Minimum 8 caractères	`secret` (6 caractères)
Mots courants	Pas dans la liste des mots courants	`password`, `123456`
Numérique	Pas entièrement numérique	`12345678`

5.13.4. Protection contre les injections

Django ORM protège automatiquement contre les injections SQL, mais HairBnB ajoute des validations supplémentaires.

Figure 22. Protection anti-injection

5.14. Monitoring et logging

5.14.1. Surveillance en temps réel

Configuration des logs

HairBnB utilise un système de logging multi-niveaux pour tracer toutes les activités sensibles.

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'loggers': {
        'geoip_blocker': {
            'handlers': ['geoip_file'],
            'level': 'INFO',
            'propagate': False,
        },
    },
}

Table 25. Types de logs surveillés
Type de log	Fichier	Événements tracés
Géolocalisation	`geoip_blocked.log`	Tentatives d’accès par pays
Sécurité	`security.log`	Authentifications échouées
API	`api_access.log`	Accès aux endpoints sensibles
Erreurs	`error.log`	Erreurs système et exceptions

5.14.2. Traçabilité des accès

Figure 23. Système de traçabilité

5.15. Gestion des erreurs sécurisée

5.15.1. Messages d’erreur non-révélateurs

HairBnB applique le principe de "moindre information" : les erreurs ne révèlent jamais de détails techniques aux utilisateurs.

Table 26. Gestion des messages d’erreur
Situation	Message utilisateur	Log interne détaillé
Connexion échouée	"Identifiants incorrects"	"Login failed for user@email.com from IP 1.2.3.4"
Accès refusé	"Accès non autorisé"	"Unauthorized access attempt to /admin by user_id 123"
Erreur serveur	"Erreur temporaire, réessayez"	"Database connection timeout in user_profile.py:45"

Principe de sécurité appliqué :

Les utilisateurs légitimes obtiennent juste assez d’information pour comprendre le problème, mais les attaquants ne peuvent pas exploiter les détails techniques pour leurs attaques.

5.15.2. Protection des informations sensibles

Figure 24. Gestion sécurisée des erreurs

5.15.3. Efficacité du monitoring

Statistiques de surveillance

Table 27. Performance du système de monitoring
Métrique	Valeur observée	Objectif
Temps de détection anomalie	< 1 minute	Temps réel
Faux positifs	< 2%	Minimiser les alertes inutiles
Couverture des logs	95% des événements	Traçabilité maximale
Rétention des logs	6 mois	Conformité et analyse

5.16. Avantages du système complet

Table 28. Bénéfices de la configuration sécurisée
Aspect	Avant	Après
Visibilité	Aucun logging	Traçabilité complète
Réaction	Détection manuelle	Alertes automatiques
Sécurité	Erreurs révélatrices	Messages neutres
Conformité	Non documentée	Logs auditables

Apprentissage pratique :

La mise en place de ce monitoring m’a permis de découvrir des tentatives d’attaque que je n’aurais jamais remarquées autrement.
Voir les logs de géolocalisation montrer des tentatives de connexion depuis des pays inattendus a été un vrai révélateur de l’importance du logging proactif.

6. Gestion de versions et sauvegarde - Une leçon durement apprise

6.1. Les outils de gestion de version : indispensables mais dangereux

Développer une application de nos jours demande toujours un arsenal d’outils qui deviennent indispensables.

Parmi ces outils, les outils de gestion de version occupent une place centrale.

Qu’est-ce qu’un outil de gestion de version ?
Un outil de gestion de version (comme Git) permet de :
- Suivre l’évolution du code source dans le temps
- Collaborer à plusieurs sur le même projet
- Revenir à une version antérieure en cas de problème
- Fusionner les modifications de différents développeurs

On parle surtout de Git & GitHub qui sont devenus les standards de l’industrie.

6.2. Mon expérience traumatisante avec Git

"J’ai eu un problème pendant un push vers le repository Git qui m’a fait perdre beaucoup de données, et je ne sais pas si c’était à cause de quoi exactement.
Par hasard, j’avais fait une copie de sauvegarde la veille et c’est ça qui a sauvé des semaines de travail.
J’avoue que cette expérience m’a traumatisé.
Perdre des semaines de développement en une seconde, c’est quelque chose qui marque !
Et c’est pour ça que j’ai cherché à trouver une solution pour ne pas tomber dans le même cas une autre fois."

— Retour d'expérience personnel

6.3. L’idée de la sauvegarde automatique

Suite à cette mésaventure, j’ai eu l’idée de créer un système de sauvegarde automatique indépendant de Git.

Le principe :

Un script qui se lance au démarrage du serveur : * Sauvegarde automatique des répertoires hairbnb_backend et hairbnb_frontend

Surveillance en temps réel des modifications.
Sauvegarde organisée par jour de la semaine.

Figure 25. Architecture du système de sauvegarde

6.4. Fonctionnement du système de sauvegarde

6.4.1. Le script principal : BackupSurveillance.ps1

Table 29. Fonctionnalités principales du script
Fonctionnalité	Description	Avantage
Surveillance temps réel	FileSystemWatcher détecte chaque modification	Réaction immédiate aux changements
Sauvegarde intelligente	Une seule sauvegarde par dossier par jour	Évite les sauvegardes redondantes
Organisation temporelle	Dossiers nommés par jour de la semaine	Rotation automatique sur 7 jours
Notifications visuelles	Messages de confirmation des sauvegardes	Feedback utilisateur rassurant

Figure 26. Processus de sauvegarde automatique

Figure 27. Console des logs de surveillance des modifications

6.4.2. Le lanceur : LancerBackup.bat

@echo off
powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\Users\Admin\Documents\WindowsPowerShell\BackupSurveillance.ps1"
.Analyse du script de lancement
|===
|Paramètre |Fonction |Importance
|@echo off
|Masque les commandes à l'exécution
|Interface propre
|-ExecutionPolicy Bypass
|Ignore les restrictions PowerShell
|Permet l'exécution du script
|-WindowStyle Hidden
|Lance en arrière-plan invisible
|Pas d'interférence utilisateur
|-File "chemin.ps1"
|Spécifie le script à exécuter
|Ciblage précis
|===

6.4.3. Logique de sauvegarde intelligente

Le script évite les sauvegardes redondantes grâce à un système de marquage :

Vérification si déjà sauvegardé aujourd'hui
if (-not $backedUpToday[$rootFolder]) {
# Effectuer la sauvegarde
$backedUpToday[$rootFolder] = $true
} else {
# Juste logger, pas de nouvelle sauvegarde
Write-Host "Déjà sauvegardé aujourd'hui : $folderName"
}

Table 30. Avantages de cette approche
Avantage	Explication	Impact
Performance	Évite les copies inutiles multiples	Économie d’espace disque et temps
Organisation	Une sauvegarde par jour maximum	Structure claire et prévisible
Simplicité	Logique facile à comprendre	Maintenance aisée du script
Fiabilité	Pas de conflit de fichiers	Sauvegardes cohérentes

6.5. Bénéfices du système de sauvegarde

Table 31. Comparaison avant/après la mise en place
Aspect	Avant (Git seul)	Après (Git + Sauvegarde auto)
Sécurité données	Dépendance totale à Git	Double protection indépendante
Fréquence sauvegarde	Manuel (irrégulier)	Automatique quotidien
Stress développeur	Peur permanente de perdre du code	Sérénité grâce au filet de sécurité
Récupération	Complexe (Git recovery)	Simple (copie de fichier)

"Suite à cette mésaventure avec Git, j’ai eu l’idée de créer un système de sauvegarde automatique indépendant.
J’avais une vision claire de ce que je voulais :
- Un script qui se lance au démarrage du serveur.
- Surveillance en temps réel des modifications.
- Sauvegarde automatique des répertoires hairbnb_backend et hairbnb_frontend.
- Organisation par jour de la semaine pour une rotation automatique.
Je dois être honnête : ce script a été généré à 90% par l’intelligence artificielle.
Mon rôle a été de définir précisément l’idée, les spécifications, le comportement souhaité et comment ça devait fonctionner.
L’IA m’a ensuite généré le script PowerShell complet.
Après la génération, j’ai fait quelques ajustements pour l’adapter à mon environnement, je l’ai intégré dans mon système et j’ai réglé quelques soucis qui sont apparus plus tard lors des tests.
Cette expérience m’a appris que l’IA peut être un formidable accélérateur de développement quand on sait bien exprimer ses besoins.
Mon expertise résidait dans la conception de la solution, l’analyse des besoins et l’intégration finale, tandis que l’IA excellait dans l’implémentation technique pure."

— Clarifications

7. Conclusion

En rédigeant ce rapport, j’avais pour ambition de rendre la sécurité informatique accessible et captivante.

J’ai fait de mon mieux pour vulgariser les concepts techniques et maintenir un équilibre entre exhaustivité et lisibilité.

Je dois avouer qu’avec le recul, j’aurais peut-être pu condenser davantage certaines sections - il y a encore de nombreux aspects techniques que j’ai volontairement omis pour ne pas surcharger le document.

La sécurité a été l’aspect le plus passionnant de ce projet pour moi.

L’implémentation de chaque couche de protection était un véritable défi technique que j’ai adoré relever.

J’espère sincèrement que cette passion transparaît malgré la densité technique inévitable du sujet.

Mon objectif était de créer un document à la fois informatif pour les lecteurs techniques et compréhensible pour ceux moins familiers avec la cybersécurité.

Si j’ai réussi à transmettre ne serait-ce qu’une partie de l’enthousiasme que j’ai ressenti en développant ces fonctionnalités de sécurité, alors cette section aura atteint son but.

Merci pour votre lecture attentive et vos retours constructifs.

8. Lexique Technique

8.1. Technologies et Frameworks

Terme

Définition

Android Keystore

Système de stockage sécurisé intégré à Android pour les clés cryptographiques et données sensibles

API (Application Programming Interface)

Interface de programmation permettant la communication entre différents composants logiciels

AsciiDoc

Langage de balisage léger pour la rédaction de documentation technique

Django

Framework web Python haute performance pour le développement d’applications web sécurisées

Django REST Framework

Extension de Django spécialisée dans la création d’APIs REST

Firebase Authentication

Service d’authentification de Google Cloud Platform gérant les identités utilisateur

Flutter

Framework open-source de Google pour développer des applications multiplateformes

Geoapify

Service API de géolocalisation et cartographie

Nginx

Serveur web et reverse proxy haute performance

Provider Pattern

Architecture Flutter pour la gestion centralisée de l’état de l’application

Stripe

Plateforme de paiement en ligne conforme PCI DSS Level 1

PostgreSQL

Système de gestion de base de données relationnelle open source

8.2. Concepts de Sécurité

Terme

Définition

Authentification

Processus de vérification de l’identité d’un utilisateur

Autorisation

Mécanisme déterminant les permissions d’accès d’un utilisateur authentifié

CORS (Cross-Origin Resource Sharing)

Mécanisme permettant à une page web d’accéder à des ressources d’un autre domaine

CSRF (Cross-Site Request Forgery)

Attaque exploitant la confiance d’un site web envers un utilisateur authentifié

Défense en Profondeur

Stratégie sécuritaire utilisant plusieurs couches de protection indépendantes

Deep Linking

Fonctionnalité permettant d’ouvrir directement un écran spécifique d’une app via un lien

DDoS (Distributed Denial of Service)

Attaque visant à rendre un service indisponible en le saturant de requêtes

Échappement (Escaping)

Conversion de caractères spéciaux pour éviter les injections de code

Hashage

Transformation irréversible de données en empreinte numérique unique

HTTPS (HTTP Secure)

Version sécurisée du protocole HTTP utilisant le chiffrement SSL/TLS

Injection

Attaque consistant à insérer du code malveillant dans une application

JWT (JSON Web Token)

Standard pour la transmission sécurisée d’informations entre parties

Rate Limiting

Technique limitant le nombre de requêtes par unité de temps

Reverse Proxy

Serveur intermédiaire recevant les requêtes et les transmettant aux serveurs backend

SSL/TLS (Secure Socket Layer/Transport Layer Security)

Protocoles de chiffrement sécurisant les communications sur Internet

XSS (Cross-Site Scripting)

Attaque injectant du code JavaScript malveillant dans une page web

8.3. Standards et Réglementations

Terme

Définition

GDPR/RGPD

Règlement Général sur la Protection des Données, législation européenne sur la vie privée

ISO 27001

Norme internationale pour les systèmes de management de la sécurité de l’information

NIST

National Institute of Standards and Technology, organisme américain de normalisation

OWASP

Open Web Application Security Project, communauté dédiée à la sécurité web

PCI DSS

Payment Card Industry Data Security Standard, norme de sécurité pour les paiements

8.4. Headers de Sécurité

Header

Fonction

Content-Security-Policy

Définit les sources autorisées pour le contenu d’une page web

Strict-Transport-Security

Force l’utilisation de HTTPS pendant une durée déterminée

X-Content-Type-Options

Empêche l’interprétation automatique du type MIME par le navigateur

X-Frame-Options

Contrôle l’affichage d’une page dans une frame (protection clickjacking)

X-XSS-Protection

Active le filtre XSS intégré des navigateurs

8.5. Acronymes Techniques

Acronyme

Signification

Certificate Authority (Autorité de Certification)

CNIL

Commission Nationale de l’Informatique et des Libertés

CVV

Card Verification Value (Code de sécurité carte bancaire)

DNS

Domain Name System (Système de noms de domaine)

DNSSEC

DNS Security Extensions (Extensions de sécurité DNS)

HTTP

HyperText Transfer Protocol

Internet Protocol

REST

Representational State Transfer

SIEM

Security Information and Event Management

URL

Uniform Resource Locator

WAF

Web Application Firewall

8.6. Concepts de Développement

Terme

Définition

Backend

Partie serveur d’une application gérant la logique métier et les données

Frontend

Interface utilisateur d’une application

Middleware

Composant logiciel interceptant et traitant les requêtes

Moindre Privilège

Principe accordant uniquement les permissions strictement nécessaires

Obfuscation

Technique rendant le code source difficile à comprendre

ProGuard/R8

Outils d’optimisation et d’obfuscation pour Android

Regex (Expression Régulière)

Motif de caractères utilisé pour la validation et recherche de texte

Sanitisation

Nettoyage des données d’entrée pour éliminer les éléments dangereux

Tokenisation

Remplacement de données sensibles par des identifiants non sensibles

Validation

Vérification de la conformité des données selon des règles définies

9. Tableau des Sources

9.1. Sources de Documentation Officielle

Technologie/Standard

Source Officielle

Section Pertinente

Django Security

https://docs.djangoproject.com/en/stable/topics/security/

Sécurité Backend, Middleware, CSRF

Flutter Security

https://docs.flutter.dev/security

Architecture Frontend, Validation

Dart Security

https://dart.dev/guides/language/effective-dart/usage

Bonnes pratiques Flutter

Firebase Authentication

https://firebase.google.com/docs/auth

Authentification, Gestion sessions

Firebase Security Rules

https://firebase.google.com/docs/rules

Protection des données

Stripe Security

https://stripe.com/docs/security

Traitement paiements, PCI DSS

Nginx Security

https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Configuration SSL/TLS, Reverse Proxy

OWASP Guidelines

https://owasp.org/www-project-top-ten/

Vulnérabilités web, Headers sécurité

RGPD/GDPR

https://gdpr.eu/what-is-gdpr/

Protection données personnelles

SSL/TLS Standards

https://datatracker.ietf.org/doc/html/rfc8446

Protocoles chiffrement (TLS 1.3)

HTTP Security Headers

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

Configuration headers sécurité

Python Security

https://docs.python.org/3/library/security_warnings.html

Bonnes pratiques Python

CNIL (France)

https://www.cnil.fr/fr/reglement-europeen-protection-donnees

Conformité RGPD, Sanctions

Mozilla SSL Config

https://ssl-config.mozilla.org/

Configuration SSL recommandée

10. Sources Complémentaires

Ressource

URL

Utilisation

Let’s Encrypt

https://letsencrypt.org/docs/

Certificats SSL gratuits

JWT.io

https://jwt.io/introduction/

JSON Web Tokens

Nginx Rate Limiting

https://www.nginx.com/blog/rate-limiting-nginx/

Protection DDoS

Django Channels Security

https://channels.readthedocs.io/en/stable/topics/security.html

WebSockets sécurisés

1. CNIL : "Le montant des sanctions pécuniaires peut s’élever jusqu’à 20 millions d’euros ou dans le cas d’une entreprise jusqu’à 4 % du chiffre d’affaires annuel mondial" Article 83 du RGPD : "amendes RGPD pouvant s’élever jusqu’à 20 000 000 EUR ou, dans le cas d’une entreprise, jusqu’à 4 % du chiffre d’affaires annuel mondial" | Exemples de sanctions récentes : Meta : 1,2 milliard d’euros (mai 2023) Google : 50 millions d’euros par la CNIL française (2019)